DevW.ai Conference 2026

Archeologie logicielle
a l'ere de l'IA

Quand l'IA deterre la connaissance perdue d'un systeme legacy

Saif Jerbi Tech Lead @ TotalEnergies Digital Factory

Le constat

« Le plus grand risque d'un systeme legacy, ce n'est pas qu'il tombe en panne. C'est que plus personne ne sache pourquoi il fonctionne. »

Le contexte

Le systeme

Une plateforme developpee depuis les annees 90, source de verite pour les raffineurs

Donnees capteurs

Des centaines de tags temps reel, debitmetres, niveaux, temperatures.

Planning et scheduling

Ordonnancement des operations, gestion des campagnes, suivi des batchs.

Laboratoire et qualite

Analyses produits, specifications, conformite des bruts et melanges.

Mass balance et mouvements

Bilan matiere quotidien, suivi des transferts entre bacs et unites.

Speaker

Saif Jerbi

Tech Lead @ TotalEnergies Digital Factory
10+ ans de dev logiciel onPrem et cloud, secteur banque et assurance
Rejoint TotalEnergies Digital Factory il y a 3 ans pour le secteur energie
Pilote un projet de modernisation legacy par agents IA

L'histoire

30 ans d'histoire

De la creation a la transformation : une frise des moments cles

Annees 90
La naissance

30 ans d'evolution. Robuste, solide, mais archaique.

2018-2022
Les tentatives

Estimation 5-7 ans. Blocages, manque d'info, reports.

2025
Le declic

Agents IA valides sur des projets moins complexes.

2026
Le moment

Archeologie logicielle IA sur le systeme le plus critique.

Pour comprendre ou on en est, il faut remonter le fil. Le systeme est ne dans les annees 90. Il a survecu a tout — restructurations, changements d'equipe, migrations de serveurs. Il est devenu la source de verite pour toute la raffinerie. Entre 2018 et 2022, il y a eu plusieurs tentatives de modernisation. A chaque fois, meme scenario : on monte une equipe, on estime 5 a 7 ans de travail, on commence a documenter... et on se rend compte que personne ne sait exactement comment ca marche. Les projets se sont enlises, pas par manque de budget, mais par manque de connaissance. Puis en 2025, on a commence a experimenter les agents IA sur des projets moins critiques — de la generation de documentation, de l'analyse de code. Et les resultats etaient bluffants. Pas parfaits, mais bluffants. Assez pour se dire : et si on attaquait le gros morceau ? En 2026, c'est ce qu'on a fait.

La complexite

~2M lignes de code

Un systeme critique depuis les annees 90, sans documentation

Code PL/SQL

Pres de 2000 fichiers, +200 packages. Conventions hongroises, aucun commentaire metier.

Config en base

Des centaines de classes et hierarchies d'attributs, accessibles uniquement via APIs.

+200 jobs planifies

Batchs quotidiens, mass balance de 700 debitmetres, orchestration par config.

Aucune documentation

Les specs sont dans la tete des experts. Certains sont partis, d'autres ont oublie.

Maintenant, parlons de l'echelle du probleme. On parle de pres de 2 millions de lignes de PL/SQL. Plus de 200 packages. Le code utilise des conventions de nommage hongroises — si vous ne connaissez pas, c'est un style ou les noms de variables commencent par un prefixe qui indique leur type. Par exemple tfeGera1GAC. Bonne chance pour comprendre ce que ca fait sans documentation. Et justement, il n'y a aucun commentaire metier dans le code. La config metier est stockee en base de donnees — des centaines de classes, des hierarchies d'attributs imbriquees, accessibles uniquement via des APIs proprietaires. Il y a plus de 200 jobs planifies qui tournent chaque jour — certains toutes les heures, d'autres une fois par jour a 3h du matin. Et la cerise : aucune documentation technique ou fonctionnelle. Les specs sont dans la tete de 3 ou 4 experts metier. Certains sont partis. D'autres ne se souviennent plus des details. C'est ca, l'archeologie logicielle — fouiller dans un systeme que plus personne ne comprend entierement, et reconstruire la connaissance piece par piece.

Le piege

Le reflexe vs la realite

Pourquoi la reecriture totale n'est pas la bonne reponse

Le reflexe

Pointer un LLM sur le code legacy
Lui demander de reecrire en Python
Resultat : du code qui compile
Mais qui ne comprend pas le metier

Notre approche

Creer des agents IA archeologues
Reconstruire la connaissance d'abord
Valider avec les experts metier
Puis seulement generer du code

C'est le slide le plus important du talk. Quand on decouvre les LLM, le reflexe naturel c'est de prendre tout le code legacy, de le donner a l'IA et de dire "reecris-moi ca en Python". Et ca marche — en apparence. Le code compile, les tests unitaires passent. Mais quand on met en production, tout s'ecroule. Pourquoi ? Parce que l'IA ne comprend pas le metier. Elle ne sait pas que tel debitimetre doit etre ignore quand il est en maintenance. Elle ne sait pas que le changement d'heure ete-hiver cree un trou d'une heure dans les donnees. Elle ne connait pas les conventions implicites qui n'existent que dans la tete des operateurs. Notre approche, c'est l'exact inverse. On ne touche pas au code au debut. On commence par reconstruire toute la connaissance metier. On documente, on fait valider par les experts, on fige un perimetre clair. Et seulement apres, une fois qu'on sait exactement ce que le code doit faire, on genere. La documentation est le vrai livrable. Le code, c'est un sous-produit.

Gouvernance

Propriete intellectuelle

Ce que l'IA peut voir, ce qu'elle ne doit pas toucher

Notre code metier

PL/SQL ecrit par nos equipes
Config et regles metier en base
Jobs et orchestrations internes
L'IA analyse, documente, reimplemente

Code editeur

APIs et librairies tierces
Implementation interne du systeme
Instruction claire : ne pas analyser
Consommer les APIs comme des boites noires

Avant d'aller plus loin, un point essentiel : la propriete intellectuelle. Quand on donne acces a une IA a du code industriel, il faut etre tres clair sur les frontieres. On a defini ca des le jour 1, noir sur blanc. D'un cote, notre code metier — le PL/SQL ecrit par nos equipes, la config en base, les jobs planifies. Ca, c'est notre propriete. L'IA peut l'analyser, le documenter, le reimplementer. De l'autre cote, le code de l'editeur du systeme. Ses APIs internes, ses librairies, son implementation. Ca, on n'y touche pas. L'instruction pour les agents est claire : consommez les APIs comme des boites noires, n'essayez jamais de comprendre comment elles fonctionnent en interne. C'est une frontiere a la fois juridique et technique qu'il faut poser tres tot. Si vous ne le faites pas, vous allez avoir des surprises desagreables.

Le harness

La boite a outils

Les briques techniques qui rendent tout le reste possible

Claude Code + Opus / Sonnet

Orchestrateur principal. Claude Opus pour l'analyse complexe et la generation, Sonnet pour les taches rapides.

MCP Server Legacy

Expose les APIs et la BDD du systeme legacy comme outils MCP. Les agents interrogent le systeme sans connaitre son implementation.

RTK

Optimisation des tokens echanges avec les agents. Reduit le bruit, maximise le contexte utile.

LikeC4

Architecture as code. Documente et visualise les composants et dependances du systeme legacy.

Le harness

Les agents specialises

Chaque agent a son role, ses skills, ses limites claires

Legacy Code Analyzer

Navigue +200 packages PL/SQL, decode les conventions hongroises, trace les dependances entre packages.

Doc Generator Agent

Skill Confluence avec template structure : sections, diagrammes, regles metier. Recoit les analyses, remplit le template et publie sur Confluence.

Business Process Engine

Developpe les reimplementations Python en se basant sur les docs validees, la config et les skills.

La methode

Le pipeline

3 phases pour migrer un processus metier

Doc Generator

➔

Experts metier

➔

Code Generator

La methode

Le pipeline

Phase 1 — Reconstruire la connaissance

PL/SQL

APIs

BDD

➔

Doc Generator

Code Analyzer
API Explorer
DB Explorer

➔

Doc

Flowcharts

Regles

➔

Valid.

➔

Doc validee

Perimetre fige

PL/SQL + APIs

Donnees historiques

➔

Code Gen

➔

Code Python

Tests auto

Comparaison

Phase 1 : reconstruire la connaissance. C'est la phase la plus importante et la plus longue. Le Doc Generator prend en entree quatre sources : le code PL/SQL brut, les APIs du systeme via le MCP server, la base de donnees avec toute sa config, et une knowledge base qu'on enrichit au fur et a mesure. A partir de ces sources, il produit trois types de livrables. De la documentation fonctionnelle — des descriptions detaillees de chaque processus metier, ecrites en langage comprehensible par les experts. Des flowcharts Mermaid — des diagrammes qui montrent le flux de traitement, les conditions, les branchements. Et des regles metier extraites — les conditions de bord, les seuils, les exceptions. Tout ca est publie automatiquement sur Confluence dans un espace dedie. Pendant cette phase, les deux etapes suivantes sont grisees — on ne genere aucun code tant que la doc n'est pas validee.

La methode

Le pipeline

Phase 2 — Validation metier

PL/SQL

APIs

BDD

➔

Doc

➔

Doc

Flowcharts

Regles

➔

Experts metier

Revue Confluence
Corrections
Validation

➔

Doc validee

Perimetre fige

PL/SQL + APIs

Donnees historiques

➔

Code Gen

➔

Code Python

Tests auto

Comparaison

La methode

Le pipeline

Phase 3 — Generation du code metier

PL/SQL

APIs

BDD

➔

Doc

➔

Doc

Flowcharts

Regles

➔

Valid.

➔

Doc validee

Perimetre fige

PL/SQL + APIs

Donnees historiques

➔

Code Generator

Formula Parser
Tag Resolver
Validator

➔

Code Python

Tests auto

Comparaison

Phase 3 : la generation du code metier. C'est la qu'on commence enfin a produire du code — et pas avant. Le Code Generator prend en entree la doc validee, le perimetre fige, mais aussi le PL/SQL original, les APIs via le MCP, la knowledge base et un jeu de donnees historiques extrait du legacy. L'agent ne se contente pas de traduire du PL/SQL en Python. Il genere du code, puis le valide automatiquement en comparant ses sorties avec les vrais resultats du legacy. Si le legacy dit 42.7 tonnes pour tel debitimetre, le code genere doit dire 42.7. Pas 42.6, pas 43. C'est de la validation par les faits. Il produit du code Python, des tests automatises, et un rapport de comparaison. Les ecarts sont visibles immediatement, et l'agent corrige et re-teste en boucle. C'est ce feedback automatise qui fait converger la qualite.

La boucle

Un travail iteratif, pas magique

Chaque erreur corrigee enrichit les skills pour les prochaines generations

Debugger les cas limites

Le code genere echouait sur les cas d'exception : heures creuses, changement d'heure, debitmetres inactifs.

Mettre a jour les skills

Chaque correction alimente les instructions des agents. Les prochaines generations evitent les memes erreurs.

Donnees de test reelles

Extract legacy : input + resultats attendus. D'abord 3 mois, puis 6 mois, puis 1 an.

Validation automatisee

Comparaison automatique entre les sorties generees et les fichiers legacy.

Soyons honnetes : ce pipeline n'est pas magique. Le code genere echoue. Regulierement. Les premiers runs, c'etait un festival d'erreurs — changement d'heure ete-hiver qui creait des trous, debitmetres en maintenance ignores, arrondis qui divergeaient. C'est normal — le metier a des centaines de cas limites. Ce qui fait la difference, c'est la boucle de correction. Chaque bug corrige alimente les skills et la knowledge base des agents. La prochaine fois que l'agent rencontre un cas similaire, il sait le gerer. Pour valider, on utilise des donnees reelles extraites du legacy — d'abord 3 mois, puis 6 mois, puis 1 an. Plus la fenetre est large, plus on couvre de cas. La validation automatisee compare chaque sortie avec le fichier legacy correspondant. C'est cette boucle — generer, comparer, corriger, enrichir — qui fait converger la qualite. Pas la premiere generation, mais la dixieme.

Impact

Le gain de temps

Manuel vs Agentic IA : la comparaison sur le terrain

Manuel : 1er perimetre migre en 6 semaines, projet estime a 5 ans
Agentic : 3 semaines de setup, puis le meme perimetre migre en quelques heures
Le vrai gain : les perimetres suivants migres en heures ou jours au lieu de semaines

Les chiffres. Le premier perimetre — un processus metier complet — a ete migre manuellement en 6 semaines. Estimation du projet total en approche manuelle : 5 ans minimum. Avec les agents, il y a eu 3 semaines de setup — construction du MCP server, des skills, de la knowledge base. Du vrai travail d'ingenierie, pas un prompt ChatGPT. Mais une fois ce socle en place, le meme perimetre migre en quelques heures. Et les perimetres suivants : des heures a quelques jours au lieu de semaines. Le cout initial est amorti des le deuxieme perimetre. Plus on avance, plus les agents sont efficaces — la knowledge base s'enrichit, les skills se perfectionnent, les cas limites sont deja couverts. Cercle vertueux. Le graphe le montre : la courbe manuelle reste haute, la courbe agentic plonge apres le setup.

Lecons

Ce qu'on a appris

Les enseignements cles pour toute equipe face a un systeme legacy

Comprendre avant de coder

L'IA qui genere sans comprendre le metier cree de la dette technique moderne.

La doc est le vrai livrable

La connaissance reconstruite a plus de valeur que le code. Elle sert a tout le monde.

Specialiser les agents

Un agent generique ne suffit pas. Skills dedies + outils MCP + knowledge base = efficacite.

L'humain reste indispensable

Cadrage, pilotage, validation, debug des cas complexes. L'IA accelere, mais n'est pas 100% autonome.

Quatre lecons pour conclure. Premiere — comprendre avant de coder. Quand l'IA genere sans comprendre le metier, on cree de la dette technique moderne. Du code qui compile, qui passe les tests, mais qui fait n'importe quoi en production. On l'a appris a nos depens. Deuxieme — la documentation est le vrai livrable. Le code, on peut le regenerer. La connaissance metier reconstruite a une valeur permanente — elle sert aux devs, aux experts, aux nouveaux arrivants. Troisieme — specialisez vos agents. Un LLM generique avec un prompt de 3 lignes ne suffit pas. Il faut des skills dedies, des outils MCP, une knowledge base qui s'enrichit. C'est ca qui fait la difference entre un POC qui impressionne et un systeme qui produit en continu. Quatrieme — l'humain reste indispensable. Cadrage, pilotage, validation, debug des cas complexes. L'IA est un multiplicateur de force extraordinaire, mais elle n'est pas autonome. Et c'est rassurant.

DevW.ai

Merci !

Moderniser un systeme legacy, c'est d'abord faire de l'archeologie.
L'IA est la meilleure pelle qu'on ait jamais eue.

Saif Jerbi

𝕏 @JerbiSaif

linkedin.com/in/saifjerbi

Merci a tous pour votre attention. Je veux finir avec cette image : moderniser un systeme legacy, c'est d'abord faire de l'archeologie. Avant de construire du neuf, il faut fouiller, comprendre, documenter ce qui existe. L'IA est la meilleure pelle qu'on ait jamais eue pour ce travail — elle peut lire des millions de lignes, tracer des dependances, generer de la documentation a une vitesse qu'aucune equipe humaine ne peut atteindre. Mais c'est toujours l'humain qui decide ou creuser. C'est l'humain qui valide, qui cadre, qui dit « ca c'est correct, ca c'est faux ». Et c'est cette collaboration — IA plus humain — qui fait que ca marche. Si vous etes face a un systeme legacy dans votre organisation, si vous avez cette montagne de code que personne ne comprend plus, sachez que c'est possible. Pas facile, pas rapide a mettre en place, mais possible. Et les resultats sont la. N'hesitez pas a venir me voir apres le talk, ou a me contacter sur LinkedIn ou X. Je suis toujours content d'echanger sur ces sujets. Merci.

Archeologie logiciellea l'ere de l'IA

Le systeme

Saif Jerbi

30 ans d'histoire

~2M lignes de code

Le reflexe vs la realite

Le reflexe

Notre approche

Propriete intellectuelle

Notre code metier

Code editeur

La boite a outils

Les agents specialises

Le pipeline

Le pipeline

Le pipeline

Le pipeline

Un travail iteratif, pas magique

Le gain de temps

Ce qu'on a appris

Merci !

Archeologie logicielle
a l'ere de l'IA